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Rq)ly to Office Action of May 21, 2008 

REMARKS 

In response to the Office Action mailed May 21, 2008, Applicant respectfully requests 
reconsideration. Claims 1-28 were previously pending in this application. By this amendment, 
claims 1, 7, 8, 14, 15, 21, 22 and 28 have been amended. Claims 6, 13, 20 and 27 have been 
canceled without prejudice or disclaimer. As a result, cMms 1-5, 7-12, 14-19, 21-26 £ind 28 are 
pending for examination with claims 1, 8, 15 and 22 being independent. No new matter has been 
added. 

As a preliminary matter, Applicant notes that the independent claims have been amended 
as suggested on page 2 of the Office Action in order to advance prosecution as suggested in the 
Office Action. Applicant notes that no objections or rejections have been made on page 2 of the 
Office Action and the amendments are not made in response to any objection or rejection. 

In addition, dependent claims 7 and 21 have been amended for consistency purposes. 
Claims 6 and 20 have been canceled and their subject matter has been incorporated into 
independent claims 1 and 15. 

Dependent claims 21 and 28 have also been amended for consistency purposes. Claims 
13 and 27 have been canceled and their subject matter has been incorporated into independent 
claims 8 and 22, respectively. 

Rejections Under 35 U.S .C. § 103. I 

The Office Action rejected claims 1, 6, 7, 15, 20, and 21 (including independent claims 
1 and 15) under 35 U.S.C. 103(a) as allegedly being unpatentable over Applicant's Admitted 
Prior Art ("Admitted Art") in view of Craft et al., US Patent No. 6,687,758 ("Craft"). 
Apphcant respectfully disagrees. 

A. Independent Claim 1 

Claim 1, as amended, recites: 

A method for transferring control between a first network interface 
controller and at least a second network interface controller in a multiple network 
interface device, the method comprising: 
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after the first network interface controller sends an identifier associated 
with a memory location in the multiple network interface device to a second 
device and the identifier and an associated data field are received by the second 
network interface controller in the multiple network interface device from the 
second device, receiving a message from the second network interface controller in 
the multiple network interface device by a program component of the multiple 
network interface device, the message indicating the reception of the identifier 
associated with the memory location in the multiple network interface device and 
the associated data field from the second device, wherein the second network 
interface controller has no knowledge of the identifier and the associated data 
field, and wherein the first network interface controller and the second network 
interface controller operate under a remote direct memory access (RDMA) 
protocol; 

passing the identifier to the program component; 

querying the first network interface controller to supply the program 
component with a list of identifiers generated by the first network interface 
controller and associated memory locations in multiple network interface device 
memory; 

identifying, by the program component, that the first network interface 
controller generated the identifier; and 

transmitting the memory location associated with the identifier to the 
second network inteiface controller, wherein the second network interface 
controller transmits the associated data f ield to the memory location. 
(Emphasis added). 

On page 5, the Office Action concedes that the Admitted Art "does not show the 
particular steps recited in the claim for handling identifiers generated by one NIC and received 

by another NIC in the same machine, in cases when control is transfeixed [paths changed] 
between a first network interface and at least a second network interface in a multiple network 
interface device." The Office Action then states, on page 6, that Craft teaches limitations of 
claim 1. 

Applicant respectfully notes that claim 1 has been amended to incorporate the subject 
matter of claim 6 and to thus recite that the first network interface controller and the second 
network interface controller operate under a remote direct memory access (RDMA) protocol 
(emphasis added). The Office Action rejected claim 6 alleging that the Admitted Art in view of 
Craft "shows that the first network interface and the second network interface operate under a 
remote direct memory access (RDMA) protocol (par. [0003]-[0005] in Applicant's admitted 
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prior art; col. 4, lines 40-42 in Craft)." Applicant respectfully notes that Craft discusses that 
upon matching the packet summary with the Communication Control Block (CCB), assuming no 
exception conditions exist, the data of the packet, without network or trzinsport layer headers, is 
sent by direct memory access (DMA) units to the destination in storage 23 denoted by the CCB, 
which may, for example, be a file cache for an application (col. 4, lines 37-43) (emphasis added). 
This is the only portion of Craft where direct memory access is mentioned. Claim 1 recites that 
the first network interface controller and the second network interface controller operate under a 
remote direct memory access (RDM A) protocol rather than the direct memory access (DMA). 

Furthermore, the Office Action states that Craft teaches "receiving a message from the 
second network interface controller in the multiple network interface device [INIC 22 sends the 
packet that it cannot process according to the fast-path connection to the INIC device driver] 
(col. 6 lines 43-47) by a program component of the multiple network interface device [at least 
one or more of the INIC device driver (64), the ATCP stack (62), and the port aggregation driver 
(66)] (Fig. 1), the message indicating the reception of the identifier and the associated data field 
[INIC 22 sends the packet that it cannot process according to the fast-path connection to the 
INIC device driver, which alerts the port aggregation driver (66) of fast-path connection 
migration] (col. 5 lines 30-34)." 

Craft is directed to at least one intelligent network interface card (INIC) that is coupled to 
a host computer to offload protocol processing for multiple network connections, reducing the 
protocol processing of the host (Abstract). A host computer 20 of Craft has a CPU 24, a memory 
21, storage 23, a first INIC 22 and a second INIC 25 (col. 2, lines 19-21; Fig. 1). Craft discusses 
that INIC 22 chooses whether to send a packet received from a network channel 32-35 to the 
host memory 21 for slow-path processing of the headers by the CPU 24 running protocol stack 
60 or 62, or to send the packet data directly to a destination in storage 23 (col. 3, lines 43-47). 
The fast-path may be selected for the vast majority of data traffic having plural packets per 
message that are sequential and error-free (Craft, col. 3, lines 47-49). The fast-path avoids the 
time consuming protocol processing of each packet by the CPU 24, such as repeated copying of 
the data and repeated trips across the host memory bus 59 (Craft, col. 3, lines 49-52). The host 
memory 21 includes an ATCP protocol processing stack 62 that is used to offload selected 
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network connections to the INICs 22 and 25 for fast-path processing of messages corresponding 
to those selected connections (Craft, col. 3, lines 12-19). 

In the cited passage, Craft discusses that the INIC 22 that receives the packet cannot 
process the packet according to the fast-path connection, and instead sends the packet to the 
INIC device driver 64, which is configured to divert fast-path type message packets to the ATCP 
stack 62 for processing (col. 6, lines 42-46). This may happen when, after the fast-path 
processing has begun, port aggregation switch 37 changes the port selection for load balancing 
purposes (Craft, col. 6, lines 36-39). Thus, Craft describes sending the packet that the INIC 22 
cannot process to the INIC device driver. By contrast, claim 1 recites sending the message 
indicating the reception of the identifier associated with the memory location in the multiple 
network interface device and the associated data field (emphasis added). While it is not entirely 
clear from the Office Action whether it refers to the packet as the message indicating the 
reception of the identifier or as the identifier itself, it appears that nowhere in the reference does 
Craft teach or suggest this limitation. 

Further, claim 1 has been amended to recite, inter alia, that after the first network 
interface controller sends an identifier associated with a memory location in the multiple 
network interface device to a second device and the identifier and an associated data field are 
received by the second network interface controller in the multiple network interface device 
from the second device, receiving a message from the second network interface controller in the 
multiple network interface device ... (emphasis added). Again, Craft's packet that the INIC 22 
cannot process is different from an identifier associated with a memory location in the multiple 
network interface device. Craft discusses that a packet received at port 52 is first processed by 
mechanism 26 to generate the packet summary, a hash of the packet summary is then compared 
with the hash table, and if necessary with the CCBs cached in memory 70, to determine whether 
the packet belongs to a message for which a fast-path connection has been set up (col. 4, lines 
32-37) (emphasis added). Upon matching the packet summary with the CCB, assuming no 
exception conditions exist, the data of the packet, without network or transport layer headers, is 
sent by direct memory access (DMA) units to the destination in storage 23 denoted by the CCB, 
which may, for example, be a file cache for an application (Craft, col. 4, lines 37-42) (emphasis 
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added). Thus, Craft describes that the generated packet summary is compared with the CCB and, 
if there is a match, the data of the packet is sent to the destination in storage 23 denoted by the 
CCB. The packet described in Craft is different from an identifier associated with a memory 
location in the multiple network interface device. Thus, Craft does not teach or suggest that the 
first network interface controller sends an identifier associated with a memory location in the 
multiple network interface device to a second device and the identifier and an associated data 
field are received by the second network interface controller. 

Craft describes that when a message, such as a file write, that corresponds to the CCB is 
received by the INIC 22, a header portion of an initial packet of the message is sent to the host 
20 to be processed by the CPU 30 and protocol stack 38 (col. 4, lines 10-13). This header 
portion sent to the host contains a session layer header for the message (Craft, col. 4, lines 13- 
15). The processing of the session layer header by ATCP stack 62 identifies the data as 
belonging to the file and indicates the size of the message, which are used by a host 20 file 
system to reserve a destination for the data in storage 23 (Craft, col. 4, lines 17-21). A list of 
buffer addresses for the destination in storage 23 is sent to the INIC 22 and stored in or along 
with the CCB (Craft, col. 4, lines 23-24) (emphasis added). Thus, Craft discusses that host 20 
reserves a destination for the data in storage 23 when a file write is received by the INIC 22 
(emphasis added). Therefore, again. Craft does not teach that the identifier and an associated 
data field are received by the second network interface controller in the multiple network 
interface device from the second device. 

Further, the Office Action states that Craft teaches "transmitting a memory location 
associated with the identifier to the second network interface [commanding the INIC 25 to flush 
the fast-path CCB back to the ATCP stack for processing the packet, and subsequently handing 
out the CCB to the INIC 22, which is now associated with the connection] (col. 6 lines 54-57), 
wherein the second network interface is capable of transmitting the associated data field to the 
memory location associated with the identifier when programmed with the CCB in the same way 
as the first network interface was capable of performing the recited function prior to migration of 
the fast-path connection (col. 4 lines 30-44)." Claim 1 has been amended, as suggested on page 
8 of the Office Action, to recite "transmitting the memory location associated with the identifier 
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to the second network interface controller, wherein the second network interface controller 
transmits the associated data field to the memory location." 

In the cited passage, Craft discusses that the ATCP stack 62 mdntdns a list of the CCBs 
that have been offloaded to INICs 22 and 25 and recognizes that the slow-path packet 
corresponds to a CCB that is in a fast-path state (col. 6, lines 47-50). Upon receiving this 
exception condition, the ATCP stack 62 will command the INIC 25 to flush the fast-path CCB 
back to the ATCP stack 62 (Craft, col. 6, lines 50-53). After the packet has been processed by 
the ATCP stack 62 and the state of the CCB updated to reflect that processing, the CCB can then 
be handed out to the INIC 22, which is known by port aggregation driver 66 to be associated 
with the connection (Craft, col. 6, lines 53-57) (emphasis added). Thus, in Craft, the ATCP stack 
52 processes the packet. Further, Craft states that after the packet had been processed, the CCB 
can be handed out to the INIC 22. By contrast, claim 1 recites that the second network interface 
controller transmits the associated data field to the memory location (emphasis added). Thus, 
Craft does not teach or suggest that the second network interface controller transmits the 
associated data field to the memory location, as recited in claim 1. 

In view of the foregoing, claim 1 patentably distinguishes over the Admitted Art and 
Craft, either alone or in combination. 

Claims 2-5 and 7 depend from claim 1 and are allowable for at least the same reasons. 

Accordingly, withdrawal of the rejection of claims 1-5 and 7 is respectfully requested. 

B. Independent Claim 15 

Claim 15, as amended, recites: 

A computer readable medium having stored therein instructions for 
performing acts for transferring control between a first network interface 
controller and at least a second network interface controller in a multiple network 
interface device, the acts comprising: 

after the first network interface controller sends an identifier associated 
with a memory location in the multiple network interface device to a second 
device and the identifier and an associated data field are received by the second 
network interface controller in the multiple network interface device, receiving a 
message from the second network interface controller by a program component in 
the multiple network interface device, the message indicating the reception of the 
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identifier associated with the memory location in the multiple network interface 
device and the associated data field from the second device, wherein the second 
network interface controller has no knowledge of the identifier and the associated 

data field, and wherein the first network interface controller and the second 
network interface controller operate under a remote direct memory access 
(RDMA) protocol; 

passing the identifier to the progrzim component; 

querying the first network interface controller to supply the program 
component with a list of identifiers generated by the first network interface 
controller and associated memory locations in multiple network interface device 
memory; 

identifying, by the program component, that the first network interface 
controller generated the identifier; and 

transmitting the memory location associated with the identifier to the 
second network interface controller, wherein the second network interface 
controller transmits the associated data field to the memory location. 
(Emphasis added). 

On page 9, the Office Action states that the Admitted Art in view of Craft "shows a 
computer readable medium having stored therein instructions for performing acts of method 1." 
Claim 15 has been amended similarly to claim 1. As should be clear from the above discussion in 
connection with claim 1, neither the Admitted Art nor Craft teaches or suggests all the limitations 
of claim 15. Li particular, neither the Admitted Art nor Craft teaches or suggests "an identifier 
associated with a memory location in the multiple network interface device," as recited in claim 
15. Further, neither the Admitted Art nor Craft teaches or suggests "transmitting the memory 
location associated with the identifier to the second network interface controller, wherein the 
second network interface controller transmits the associated data field to the memory location," 
as also recited in claim 15. 

In view of the foregoing, claim 15 patentably distinguishes over the Admitted Art and 
Craft, either alone or in combination. 

Claims 16-19 and 21 depend from claim 15 and are allowable for at least the same 
reasons. 

Accordingly, withdrawal of the rejection of claims 15-19 and 21 is respectfully requested. 
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Rejections Under 35 U.S.C. §103. II 
The Office Action rejected claims 8-14 and 22-28 (including independent claims 8 and 
22) under 35 U.S.C. 103(a) as allegedly being unpatentable over the Admitted Art in view of 
Craft, in view of Starr et al., US Patent No. 6,807,581 ("Starr"), and in further view of Recio et 
al.. An RDMA Protocol Specification (Version 1.0) ("Recio"). Applicant respectfully disagrees. 

C. Independent Claim 8 

Claim 8, as amended, recites: 

A method for transferring control between a first network interface 
controller and at least a second network interface controller in a host computer 
including the first network interface controller and the second network interface 
controller, the method comprising: 

receiving an identifier from a remote computer by the at least a second 
network interface controller, the identifier generated by the first network interface 
controller and associated with a memory location in the host computer, wherein 
the second network interface controller has no knowledge of the identifier £ind the 
associated data field, and wherein the first network interfiice controller and the 
second network inteiface controller operate under a remote direct memory access 
(RDMA) protocol; 

sending a message to a program component indicating the reception of the 
identifier, the program component queries the first network interface controller for 
a list of identifiers generated by the first network interface controller and 
associated memory locations in the host computer; 

passing the identifier received from the remote computer to the program 
component; 

searching the list of identifiers for the identifier; 

when the list of identifiers includes the identifier received from the remote 
computer, receiving a memory location associated with the identifier, and 

when the list of identifiers does not include the identifier received from the 
remote computer, invalidating the identifier received from the remote computer. 
(Emphasis added). 

On page 13, the Office Action concedes that the Admitted Art does not teach "sending a 
message to a program component indicating the reception of the identifier, the program 
component configured to query the first network interface controller for a list of identifiers 
generated by the first network interface controller and associated memory locations in the host 
computer; passing the identifier received from the remote computer to the program component; 
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searching the list of identifiers for the identifier; if the hst of identifiers includes the identifier 
received from the remote computer, receiving a memory location associated with the identifier; 
and if the list of identifiers does not include the identifier received from the remote computer, 
invalidating the identifier received from the remote computer." 

The Office Action then alleges that Craft teaches "sending a message to a program 
component indicating the reception of the identifier [INIC 22 sends the packet that it cannot 
process according to the fast-path connection to the INIC device driver, wherein a program 
component is interpreted to include at least one or more of the INIC deice driver (64), the ATCP 
stack (62), and the port aggregation driver (66)] (col. 6 lines 43-47; Fig. 1), the progrzim 
component configured to query the first network interface controller for a list of identifiers 
[conmianding the INIC 25 to flush the fast-path CCB back to the ATCP stack, wherein CCB 
contains a list of identifiers] (col. 3 lines 59 to col. 4 line 9; col. 6 lines 47-53); and passing the 
identifier received from the remote computer to the program component [passing the packet that 
includes identifier in the packet summary to the INIC driver] (col. 4 lines 30-43; col. 6 lines 43- 
47)." Applicant respectfully disagrees. 

As should be clear from the above discussion. Craft does not teach or suggest "the 
identifier generated by the first network interface controller and associated with a memory 
location in the host computer," as recited in claim 8. Further, Craft does not teach or suggest 
"sending a message to a program component indicating the reception of the identifier," as also 
recited in claim 8. 

On page 15, the Office Action concedes that the Admitted Art does not show "searching 
the list of identifiers for the identifier; if the list of identifiers includes the identifier received 
from the remote computer, receiving a memory location associated with the identifier; and if the 
list of identifiers does not include the identifier received from the remote computer, invalidating 
the identifier received from the remote computer." The Office Action alleges that Starr "shows: 
searching the list of identifiers [comparing packet summary with CCB hashes and CCB cache] 
(Fig. 3 step (110); col. 9 lines 40-44); if the list of identifiers includes the identifier received 
from the remote computer, receiving a memory location associated with the identifier [if the 
packet suntmiary matches a CCB, receiving a memory location according to a file system] (Fig. 3 
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steps (120) and (122); col. 9 lines 55-61); and if the list of identifiers does not include the 
identifier received from the remote computer [if the packet summjiry does not match a CCB] 
(Fig. 3 step (110); col. 9 lines 44-46, [sending packet to stack for slow-path processing] (Fig. 3 
step (112); col. 9 lines 44-46)." 

It is not clear which identifiers in the packet summaries of Starr the Office Action refers 
to when stating that Starr teaches the identifier recited in claim 8. Starr describes that when a 
network packet that is directed to the host 20 arrives at the INIC 22, the headers for that packet 
are processed by the sequencers 52 to validate the packet and create a summary or descriptor of 
the packet, with the summary prepended to the packet and stored in frame buffers 77 and a 
pointer to the packet stored in a queue (col. 6, lines 58-63). The summary is a status word (or 
words) that describes the protocol types of the packet headers and the results of checksumming 
(Starr, col. 6, lines 63-66). Nowhere does Starr even mention that the packet summary includes 
the identifier associated with a memory location in the host computer. Thus, Starr does not teach 
or suggest the identifier generated by the first network interface controller and associated with a 
memory location in the host computer recited in claim 1. 

Further, on page 16, the Office Action states that "Applicant's admitted prior art in view 
of Craft and in further view of Starr does not show invalidating the identifier received from the 
remote computer if the list of identifiers does not include the identifier received from the remote 
computer." The Office Action alleges that Recio "shows invalidating the identifier received 
from the remote computer (page 5 lines 15-24; page 12 lines 46-50; page 21)." 

The Office Action states that "[i]t would have been obvious to one of ordinary skill in the 
art at the time of the invention to modify the method of Applicant's admitted prior art in view of 
Craft and in further view of Starr by invalidating the identifier received from the remote 
computer if the list of identifiers does not include the identifier received from the remote 
computer, and, therefore, the packet is sent to stack for slow-path processing (Fig. 3 step (112) in 
Starr) in order to prevent a remote host from subsequent access to the memory location 
associated with the identifier once the packet is processed, which is the feature provided by the 
RDMA protocol specification, wherein all of Applicant's admitted prior art. Craft, and Starr are 
using DMA for data transfer" (emphasis added). Applicant respectfully disagrees. The Office 
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Action refers to packet summaries of Craft as including an identifier associated with a memory 
location recited in claim 8 (See page 14). Similarly, the Office Action refers to packet 
summaries of Starr as including the identifier recited in cldm 8 (See page 15). 

Starr describes that a packet sent from a network such as LAN/WAN 25 is first received 
100 at the INIC 22 (col. 9, lines 22-24; Fig. 3). The network, transport £ind, optionally, session 
layer headers of that packet are then processed 102 by the sequencers 52, which validate the 
packet and create a summaiy of those headers (Starr, col. 9, lines 26-29). Thus, as also 
discussed above, the packet summary of Starr describes the packet headers. 

Further, Starr describes that for the case in which the packet is a fast-path candidate, the 
packet summary is then compared 110 with a set of fast-path connections being hzindled by the 
card, each connection represented as a CCB, by matching the summary with CCB hashes £ind the 
CCB cache (col. 9, lines 40-44). If the summary does not match a CCB held in the INIC 
memory, the packet is sent 1 12 to host memory /or processing the headers of the packet by the 
CPU running instructions from the protocol stack (Starr, col. 9, lines 44-47). Thus, when the 
packet summai y of Stai i- does not match a CCB, the headers of the packet are sent to be 
processes by the CPU. At the same time, the packet summary is a status word that describes the 
packet headers. Therefore, it is not clear why one of skill in the art would invalidate the packet 
suntmiary describing the packet headers when the packet summary does not match a CCB when, 
in such scenario, the headers are processed by the CPU. Moreover, as discussed above, it is not 
clear from the Office Action what identifier in the packet summary of StaiT the Office Action 
refers to because StaiT states that the summary is a status word (or words) that describes the 
protocol types of the packet headers and the results of checksumming (col. 6, lines 63-66). Thus, 
one of skill in the art would not be motivated to combine the Admitted Art, Craft, Starr and 
Recio to invalidate the identifier received from the remote computer when the list of identifiers 
does not include the identifier received from the remote computer. 

In view of the foregoing, claim 8 patentably distinguishes over the Admitted Art, Craft, 
Starr and Recio, either alone or in combination. 

Claims 9-12 and 14 depend from claim 8 and are allowable for at least the same reasons. 

Accordingly, withdrawal of the rejection of claims 8-12 and 14 is respectfully requested. 
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D. Independent Claim 22 

Claim 22, as amended, recites: 

A computer readable medium having stored therein instructions for 
performing acts for transferring control between a first network interface 
controller and at least a second network interface controller in a host computer 
including the first network interface controller and the second network interface 
controller, the method comprising: 

receiving an identifier from a remote computer by the at least a second 
network interface controller, the identifier generated by the first network interface 
controller and associated with a memory location in the host computer, wherein 
the second network interface controller has no knowledge of the identifier and the 
associated data field, and wherein the first network interface controller and the 
second network interface controller operate under a remote direct memory access 
(RDMA) protocol; 

sending a message to a program component indicating the reception of the 
identifier, the program component queries the first network interface controller for 
a list of identifiers generated by the first network interface controller and 
associated memory locations in the host computer; 

passing the identifier received from the remote computer to the program 
component; 

searching the list of identifiers for the identifier; 

when the list of identifiers includes the identifier received from the remote 
computer, receiving a memory location associated with the identifier; and 

when the list of identifiers does not include the identifier received from the 
remote computer, invalidating the identifier received from the remote computer. 
(Emphasis added). 

On page 19, the Office Action rejects claim 22 for the same reasons as claim 8. As 
should be clear from the above discussion in connection with claims 1 and 8, neither of the cited 
references teaches or suggests "receiving an identifier from a remote computer by the at least a 
second network interface controller, the identifier generated by the first network interface 
controller and associated with a memory location in the host computer, wherein the second 
network interface controller has no knowledge of the identifier and the associated data field, and 
wherein the first network interface controller and the second network interface controller operate 
under a remote direct memory access (RDMA) protocol; sending a message to a program 
component indicating the reception of the identifier, the program component queries the first 
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network interface controller for a list of identifiers generated by the first network interface 
controller and associated memory locations in the host computer; passing the identifier received 
from the remote computer to the program component; searching the list of identifiers for the 
identifier; when the list of identifiers includes the identifier received from the remote computer, 
receiving a memory location associated with the identifier; and when the list of identifiers does 
not include the identifier received from the remote computer, invalidating the identifier received 
from the remote compute," as recited in claim 22. 

In view of the foregoing, claim 22 patentably distinguishes over the Admitted Art, Craft, 
Starr and Recio, either alone or in combination. 

Claims 23-26 and 28 depend from claim 22 and are allowable for at least the same 
reasons. 

Accordingly, withdrawal of the rejection of claims 22-26 and 28 is respectfully requested. 
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CONCLUSION 



A Notice of Allowance is respectfully requested. The Examiner is requested to call the 
undersigned at the telephone number listed below if this communication does not place the case 
in condition for allowance. 

If this response is not considered timely filed and if a request for an extension of time is 
otherwise absent, Applicant hereby requests any necessary extension of time. If there is a fee 
occasioned by this response, including an extension fee, the Director is hereby authorized to 
charge any deficiency or credit any overpayment in the fees filed, asserted to be filed or which 
should have been filed herewith to our Deposit Account No. 23/2825, under Docket No. 



M1103.70194US00. 



Dated: August 21, 2008 



Respectfully submitted. 



By: /James H. Morris/ 

James H. Morris, Reg. No. 34,681 

Wolf, Greenfield & Sacks, P.C. 

Federal Reserve Plaza 

600 Atlantic Avenue 

Boston, Massachusetts 02210-2206 

Telephone: (617) 646-8000 



